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Detailed Action 

This Office Action is response to the application (10749702) filed on 31 December 
2003. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a), which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to 
a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 

Claims 1-3, 5-6, 8-33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Gu. U.S. App No. US 2004/0260800 in view of Oakano. U.S. App. No. US 
2002/0062485. . 

Regarding claim 1, Gu, teaches wherein a client device comprising: 

an ad-hoc client to manage connection of said client device to an ad-hoc 

wireless network (ad-hoc self-set by devices to interoperate with other devices on 

a network - Abstract, lines 3-4, Fig. 25, unit 852 - WAN); 

a DHCP client to send a DHCP discover message in response to a command 

from said ad-hoc client (Fig. 29, unit 900 -- computing device, unit 950 -Client 

device send a (DHCP BROADCAST) discover message); and 
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a tinyDHCP unit (router, modem, client terminal) to sense said DHCP discover 
message (Fig. 29, unit 900 - computing device, unit 950 - client device receive 
(DHCP BROADCAST) discover message) 

With respect to claim 1 , Gu teaches well the invention set forth above except for 
the claimed "allocate an IP address for the client device in response thereto". 

Okano teaches that it is well known to allocate an IP address for the client device 
in response thereto (a DHCP to dynamically allocate an IP address to a subscriber 
terminal - Abstract, lines 1-2, a dynamic IP address allocation is automatically 
performed by the DHCP - Page. 1 , [0006]). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Gu's invention by utilizing the DHCP system for allocating 
an IP address to the client device in response to receiving a DHCP discover message 
where as dynamic allocation is the only method which provides dynamic re-use of IP 
addresses. A network adminstrator assigns a range of IP addresses to DHCP, and each 
client computer on the LAN has its TCP/IP software configured to request an IP address 
from the DHCP server when that client computer's network interface card starts up. The 
request-and-grant process uses a lease concept with a controllable time period (as 
taught by Okano). 

Regarding claim 2, Gu and Okano together taught the client device of claim 1 , as 
described above. Gu further teaches wherein, a packet driver to provide raw access to a 
wireless network medium for at least the tinyDHCP unit without using sockets 
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functionality (FIG. 25, unit 852 include a wide area network (WAN), FIG. 30, a client 
that accesses and uses the embedded computing device 900 over the computer 
network has an exemplary client software architecture 950, which includes 
software code modules for applications 952, simple discovery 954, XML 955, 
LDAP 956, TCP/IP stack 958 (WinSock) and a network interface card (NIC) 960 that 
provides a physical connection to the computer network - Page. 30, [0559]). 

Regarding claim 3, Gu and Okano together taught the client device of claim 2, as 
described above. Gu further teaches wherein, said packet driver is a part of a packet 
capture library (a set-up and configuration process through which appropriate 
driver software is installed by a user or administrator onto the host for use in 
controlling the peripheral - Page. 1, [0006]). 

Regarding claim 5, Gu and Okano together taught the client device of claim 1 , as 
described above. Gu further teaches wherein, said DHCP client sends said DHCP 
discover message to a predetermined port that is monitored by said tinyDHCP unit 
(TCP/IP provides the ability to initiate a connection with a specified application 
running on a specific device provided both the network address of the device (IP 
address) and the application address (port) are known - Page. 7, [0122], a TCP 
socket using its IP address and an arbitrary port number. This address/port pair 
will be referenced by all incoming URL requests - Page. 23, [0398]). 



Application/Control Number: Page 5 

10/749,702 

Art Unit: 2146 

Regarding claim 6, Gu and Okano together taught the client device of claim 1 , as 
described above, Okano further teach tinyDHCP unit tests the availability of said IP 
address (the DHCP reply packets in response to the DHCP discovers and in which 
IP addresses pooled by the DHCP servers - Page. 5, [0092]). 

Regarding claim 8, Gu and Okano together taught the client device of claim 1 , as 
described above. Okano further teaches wherein, said tinyDHCP unit sends a DHCP 
offer (Fig. 2, DHCP OFFER - M6, M8) that includes the IP address (Fig. 1, - M12 
(REGISTERATION OF IP1 (IP ADDRESS) in FILTERING TABLE BY DHCP)) 

Regarding claim 9, Gu and Okano together taught the client device of claim 8, as 
described above. Okano further teaches wherein, said tinyDHCP unit sends said DHCP 
offer to a predetermined port that is monitored by said DHCP client (listener will listen 
on a TCP port for notifications sent - Page. 17, [0282], DHCP or client device 
listens for incoming connection requests on that socket and sets itself up to 
accept any incoming connections - Page. 23, [0399]). 

Regarding claim 10, Gu and Okano together taught the client device of claim 8, as 
described above. Okano further teaches wherein, said DHCP client senses said DHCP 
offer and sends a DHCP request based thereon [see above rejection], wherein said 
DHCP request includes said IP address (Fig. 2, DHCP REQUEST (M9) from 
subscriber terminal). 
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Regarding claim 1 1 , Gu and Okano together taught the client device of claim 1 0, as 
described above. Okano further teaches wherein, said DHCP client verifies availability 
of said IP address before sending said DHCP request (the DHCP reply packets in 
response to the DHCP discovers and in which IP addresses pooled by the DHCP 
servers - Page. 5, [0092]). 

Regarding claim 12, Gu and Okano together taught the client device of claim 10, as 
described above. Gu further teaches wherein, said tinyDHCP unit senses said DHCP 
request and sends a DHCP acknowledge (ACK) message in response thereto (Fig. 2, 
(DHCP "ACK" -- M11 & M12)). Okano further teaches wherein a DHCP acknowledge 
(ACK) message from within the client device (Fig. 24, user control point send "200 
OK"). 

Regarding claim 13, Gu and Okano together taught the client device of claim 1, as 
described above. Gu, further teaches wherein, said tinyDHCP unit (modem, router, 
client computer, server) is associated with a user interface to allow a user to specify 
DHCP parameters (UPnP uses SSDP to allow User Control Points to find 
Controlled devices and Services. SSDP operates in a default, completely 
automatic multicast UDP/IP based mode in addition to a server-based mode that 
uses TCP/IP for registrations and query - Page. 6, [0093]). 
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Regarding claim 14, Gu teaches wherein a method for use in connecting a client 
device to an ad-hoc network (ad-hoc self-set by devices to interoperate with other 
devices on a network - Abstract, lines 3-4, Fig. 25, unit 852 (LAN or WAN)), 

comprising: 

sending a DHCP discover message from within the client device (Fig. 29, unit 
900 (computing device), unit 950 (Client device) send a (DHCP BROADCAST) 
discover listener (message)); 

receiving said DHCP discover message within the client device (Fig. 29, unit 900 
(computing device), unit 950 (client device) receive (DHCP BROADCAST) 
discover response (message)); and 

With respect to claim 14, Gu teaches well the invention set forth above except for 
the claimed "allocating an IP address to the client device in response to receiving said 
DHCP discover message, within the client device". 

Okano teaches that it is well known to allocating an IP address to the client 
device in response to receiving said DHCP discover message, within the client device 
(a DHCP to dynamically allocate an IP address to a subscriber terminal - 
Abstract, lines 1-2, a dynamic IP address allocation is automatically performed by 
the DHCP - Page. 1, [0006]). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Gu's invention by utilizing the DHCP system for allocating 
an IP address to the client device in response to receiving a DHCP discover message 
where as dynamic allocation is the only method which provides dynamic re-use of IP 
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addresses. A network adminstrator assigns a range of IP addresses to DHCP, and each 
client computer on the LAN has its TCP/IP software configured to request an IP address 
from the DHCP server when that client computer's network interface card starts up. The 
request-and-grant process uses a lease concept with a controllable time period (as 
taught by Okano). 

Regarding claim 15, Gu and Okano together taught the method of claim 14, as 
described above. Gu further teaches wherein, sending includes sending said DHCP 
discover message to a predetermined port (TCP/IP provides the ability to initiate a 
connection with a specified application running on a specific device provided 
both the network address of the device (IP address) and the application address 
(port) are known - Page. 7, [0122], a TCP socket using its IP address and an 
arbitrary port number. This address/port pair will be referenced by all incoming 
URL requests - Page. 23, [0398]). 

Regarding claim 16, Gu and Okano together taught the method of claim 15, as 
described above. Okano further teaches wherein, receiving includes monitoring said 
predetermined port and sensing said DHCP discover message on said predetermined 
port (listener will listen on a TCP port for notifications sent - Page. 17, [0282], 
DHCP or client device listens for incoming connection requests on that socket 
and sets itself up to accept any incoming connections - Page. 23, [0399]). 
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Regarding claim 17, Gu and Okano together taught the method of claim 14, as 
described above. Okano further teaches wherein, sending a DHCP offer (Fig. 2, DHCP 
OFFER (M6), (M8)) that includes said IP address (Fig. 1, (M12) REGISTERATION OF 
IP1 (IP ADDRESS) in FILTERING TABLE BY DHCP), after allocating said IP address, 
from within the client device (Fig. 1, COMPLETION OF IP ADDRESS ALLOCATING 
BY DHCP). 

Regarding claim 18, Gu and Okano together taught the method of claim 17, as 
described above. Okano further teaches wherein testing the availability of said IP 
address before sending said DHCP offer (the DHCP reply packets in response to the 
DHCP discovers and in which IP addresses pooled by the DHCP servers - Page. 
5, [0092]). 

Regarding claim 19, Gu and Okano together taught the method of claim 17, as 
described above. Gu further teaches wherein, sending a DHCP offer [see above 
rejection] includes causing a packet driver to send said DHCP offer on a wireless 
network medium (Fig. 25, unit 852 (LAN/WAN), a set-up and configuration process 
through which appropriate driver software is installed by a user or administrator 
onto the host for use in controlling the peripheral - Page. 1, [0005]). 

Regarding claim 20, Gu and Okano together taught the method of claim 19, as 
described above. Gu further teaches wherein, said packet driver sends said DHCP offer 
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on said wireless network medium without the use of sockets functionality (FIG. 25, unit 
852 include a wide area network (WAN), FIG. 30, a client that accesses and uses 
the embedded computing device 900 over the computer network has an 
exemplary client software architecture 950, which includes software code 
modules for applications 952, simple discovery 954, XML 955, LDAP 956, TCP/IP 
stack 958 (WinSock) and a network interface card (NIC) 960 that provides a . 
physical connection to the computer network - Page. 30, [0559]). 

Regarding claim 21, Gu and Okano together taught the method of claim 17, as 
described above. Okano further teaches wherein receiving said DHCP offer within the 
client device (Fig. 2, DHCP offer (M6 & M8) in subscriber terminal); and sending, 
after receiving said DHCP offer, a DHCP request that includes said IP address from 
within the client device (Fig. 2, DHCP REQUEST (M9) from subscriber terminal). 

Regarding claim 22, Gu and Okano together taught the method of claim 21, as 
described above. Okano further teaches wherein, verifying that the IP address within 
the DHCP offer is available before sending said DHCP request (the DHCP reply 
packets in response to the DHCP discovers and in which IP addresses pooled by 
the DHCP servers - Page. 5, [0092]). 

Regarding claim 23, Gu and Okano together taught the method of claim 21 , as 
described above. Okano further teaches wherein, receiving said DHCP request within 
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the client device; and sending, after receiving said DHCP request [see above 
rejection], a DHCP acknowledge (ACK) message from within the client device (Fig. 24, 
user control point send "200 OK"). Gu further teaches wherein a DHCP acknowledge 
(ACK) message from within the client device (Fig. 2, (DHCP "ACK" - M11 & M12)) 

Regarding claim 24, Gu and Okano together taught the method of claim 23, as 
described above. Okano further teaches wherein, receiving said DHCP ACK message 
within the client device (Fig. 2, (DHCP "ACK" - M11 & M12)). 

Regarding claim 25, Gu and Okano together taught the method of claim 14, as 
described above. Okano further teaches wherein, allocating includes using dynamic 
DHCP allocation (DHCP to dynamically allocate an IP address - Abstract, lines 1- 
2). 



Regarding claim 26, Gu teaches wherein an article comprising computer readable 
storage media having instructions stored thereon that, when executed by a computing 
platform (server, client terminal), result in: 

sending a DHCP discover message from within a client device (Fig. 29, unit 900 
(computing device), unit 950 (Client device) send a (DHCP BROADCAST) discover 
listener (message)); 
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receiving said DHCP discover message within the client device (Fig. 29, unit 900 
- computing device, unit 950 -- client device receive (DHCP BROADCAST) 
discover response (message)) 

With respect to claim 26, Gu teaches well the invention set forth above except for 
the claimed "allocating an IP address to the client device in response to receiving said 
DHCP discover message, within the client device". 

Okano teaches that it is well known to allocating an IP address to the client 
device in response to receiving said DHCP discover message, within the client device 
(a DHCP to dynamically allocate an IP address to a subscriber terminal - 
Abstract, lines 1-2, a dynamic IP address allocation is automatically performed by 
the DHCP - Page. 1, [0006]). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Gu's invention by utilizing the DHCP system for allocating 
an IP address to the client device in response to receiving a DHCP discover message 
where as dynamic allocation is the only method which provides dynamic re-use of IP 
addresses. A network adminstrator assigns a range of IP addresses to DHCP, and each 
client computer on the LAN has its TCP/IP software configured to request an IP address 
from the DHCP server when that client computer's network interface card starts up. The 
request-and-grant process uses a lease conce'pt with a controllable time period (as 
taught by Okano). 
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Regarding claim 27, Gu and Okano together taught the article of claim 26, as 
described above. Gu, further teaches wherein, sending includes sending said DHCP 
discover message to a predetermined port (TCP/IP provides the ability to initiate a 
connection with a specified application running on a specific device provided 
both the network address of the device (IP address) and the application address 
(port) are known - Page. 7, [0122], a TCP socket using its IP address and an 
arbitrary port number. This address/port pair will be referenced by all incoming 
URL requests - Page. 23, [0398]). 

Regarding claim 28, Gu and Okano together taught the article of claim 27, as 
described above. Gu, further teaches wherein, receiving includes monitoring said 
predetermined port and sensing said DHCP discover message on said predetermined 
port (listener will listen on a TCP port for notifications sent - Page. 17, [0282], 
DHCP or client device listens for incoming connection requests on that socket 
and sets itself up to accept any incoming connections - Page. 23, [0399]). 

Regarding claim 29, Gu and Okano together taught the article of claim 26, as 
described above. Gu, further teaches wherein, sending a DHCP offer (Fig. 2, DHCP 
OFFER - M6, M8) that includes said IP address (Fig. 1, (M12) REGISTERATION OF 
IP1 (IP ADDRESS) in FILTERING TABLE BY DHCP), after allocating said IP address, 
from within the client device (Fig. 1, COMPLETION OF IP ADDRESS ALLOCATING 
BY DHCP). 
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Regarding claim 30, Gu teaches wherein, a client device comprising: 

a wireless network interface card (NIC) (Fig. 30, unit 960 (NIC), a network interface 

card (NIC) - Page. 30, [0559]) to provide an interface to a wireless 

network medium (radio frequency (including satellite, cell, pager, commercial 

signal sideband, etc. - Page. 28, [0530]); 

an ad-hoc client to manage connection of said client device to an ad-hoc wireless 
network (ad-hoc self-set by devices to interoperate with other devices on a 
network - Abstract, lines 3-4); 

a DHCP client to send a DHCP discover message in response to a command from said 
ad-hoc client (Fig. 29, unit 900 (computing device), unit 950 (Client device) send a 
(DHCP BROADCAST) discover listener (message)); and 
a tinyDHCP unit (modem, router, client computer, server) to sense (listen) said 
DHCP discover message (Fig. 29, unit 900 (computing device), unit 950 (client 
device) receive (DHCP BROADCAST) discover response (message)). 

With respect to claim 30, Gu teaches well the invention set forth above except for 
the claimed "allocate an IP address for the client device in response thereto". 

Okano teaches that it is well known to utilize a DHCP client to send a DHCP 
discover message in response to a command from said ad-hoc client (Fig. 2, sending 
DHCP discover -- M1-M3), allocate an IP address for the client device in response 
thereto (a DHCP to dynamically allocate an IP address to a subscriber terminal - 
Abstract, lines 1-2, a dynamic IP address allocation is automatically performed by 
the DHCP - Page. 1 , [0006]). 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Gu's invention by utilizing the DHCP system for allocating 
an IP address to the client device in response to receiving a DHCP discover message 
where as dynamic allocation is the only method which provides dynamic re-use of IP 
addresses. A network adminstrator assigns a range of IP addresses to DHCP, and each 
client computer on the LAN has its TCP/IP software configured to request an IP address 
from the DHCP server when that client computer's network interface card starts up. The 
request-and-grant process uses a lease concept with a controllable time period (as 
taught by Okano). 

Regarding claim 31 , Gu and Okano together taught the client device of claim 30, as 
described above, Gu further teaches wherein, said wireless NIC is configured (NIC) in 
accordance with the IEEE 802.1 1 (router) wireless networking standard (Fig. 25, unit 
820 personal computer communicates via unit 854 router/modem over the unit 
852 (WAN)). 

Regarding claim 32, Gu and Okano together taught the client device of claim 30, as 
described above, Gu further teaches wherein, a packet driver to provide raw access to 
said wireless network medium for the tinyDHCP unit without using sockets functionality 
(FIG. 25, unit 852 include a wide area network (WAN), FIG. 30, a client that 
accesses and uses the embedded computing device 900 over the computer 
network has an exemplary client software architecture 950, which includes 
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software code modules for applications 952, simple discovery 954, XML 955, 
LDAP 956, TCP/IP stack 958 (WinSock) and a network interface card (NIC) 960 that 
provides a physical connection to the computer network - Page. 30, [0559]). 

Claim 33 has the similar limitation as of claim 3; therefore, it's rejected under the same 
rationale as in claim 3. 

Claims 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over Gu. U.S. App 
No. US 2004/0260800 in view of Oakano. U.S. App. No. US 2002/0062485. further in 
view of Gardiner U.S. Ap. No. US 2003/0225864. 

Regarding claim 7, Gu and Okano together taught the method of claim 6, as described 
above. However, Gu and Okano do not explicitly teach said tinyDHCP unit tests the 
availability of said IP address by sending an ICMP echo request 

Gardiner teaches wherein, testing the availability of said IP address before 
sending said DHCP offer. (A host could find an unused IP address on the subnet 
using the Internet Control Message Protocol (ICMP) ping command - Page. 1, 
[0009]). 

It would have been obvious to one ordinary skilled in the art at the time the 
invention was made to combine the teachings 'of Gardiner for testing the availability of 
IP address before sending DHCP offer. Motivation would be to complement the step of 
the known art that Gu and Okano attempt to resolve such enabling a host or client to 
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obtain and reserve exclusive unique IP address with Gardner means that support 
obtaining a unique and reserved IP address. 
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Response to Arguments 

Applicant's arguments filed on 12/17/2007 have been fully considered but they 
are not persuasive. According to the applicant arguments "a tinyDHCP unit to same- 
sense said DHCP discover message and allocate an IP address for the client device in 
response therto." In response to the above argument, Gu does discloses a tinyDHCP 
which is the AutolP operative module within the client device also used for automatic 
network introduction via AutolP in the UPnP protocol. AutolP uses a predefined set of IP 
addresses and, when a device is connected to the network, it pings (sense/listen) an 
address in this address space. If it gets no replies, the device assumes that the address 
is available and assigns it to itself. To make this functionality even more useful it is 
combined with Multicast DNS, in which the device itself holds its own name. Thus it is 
not even necessary to determine what IP address the device assigned to itself, because 
its name can always be used instead. An IP Multicast is a mechanism for sending a 
single message to multiple recipients. IP multicasting is especially useful for discovery 
operations where one does not know exactly who has the information one seeks. In 
such cases, one can send a request to a reserved IP multicast address. Any services 
that can provide the requested information will also subscribe to the multicast request 
and thus be able to hear the information request and properly respond. In addition, the 
above disclosures also satisfy the functionality that allows a DHCP client within the 
device to operate as if a DHCP server were available. 

In response to the applicant arguments "receiving DHCP discover message 
within the client device or allocating an IP address to the client device in response to 
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receiving said DHCP discover message, within the client device." Gu discloses a 
computing device for dynamically self-configuring a computing device upon introduction 
on a network to interoperate (within the device) with other devices on the network where 
an addressing module operating to configure an address upon introduction of the 
computing device on the network; an announcing module operating to send a message 
announcing the address assigned to the computing device; a discovery module 
operating to listen or sense for a discovery message on the network, the discovery 
message having an identifier to identify an other computing device; a discovery 
response receiving module operating upon receipt of the discovery message to send a 
response message to the discovery message; and a description module operating upon 
receipt of a description request received by the computing device on the network for 
sending a description message defining a protocol for interaction via data messaging of 
the computing device with the other computing device, the other computing device 
configured to remotely operate the computing device. In addition, the above disclosures 
also satisfies the applicant arguments which is "the reception of such DHCP discover 
message within the originating client device or allocating an IP address of to the 
originating client device from within the device in response to the received message." 

In response to applicant arguments regarding claim 2 "a packet driver." Gu 
discloses TCP/IP stack 958 (WinSock) and a network interface card (NIC) 960 that 
provides a physical connection to the computer network which does the same 
functionality as a packet driver does. 
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In response to applicant arguments regarding claims 5, 8-10 & 12, applicant 
argues in the same terminologies wherein "tiny DHCP unit, sending, monitoring, 
requesting including IP address and response back or ACK." Gu/Okano discloses 
TCP/IP provides the ability to initiate a connection with a specified application running 
on a specific device provided both the network address of the device (IP address) and 
the application address (port) are known, a TCP socket using its IP address and an 
arbitrary (predefined) port number. This address/port pair will be referenced by all 
incoming URL requests. Gu discloses in Fig. 2, DHCP offer where DHCP or client 
device listens for incoming connection requests on that socket and sets itself up to 
accept any incoming connections. Also, the DHCP reply packets in response to the 
DHCP discover and in which IP addresses pooled by the DHCP client/server as well as 
responding with an ACK message. 

Conclusion 

Applicant's arguments filed on 12/17/2007 have been fully considered but they 
are not persuasive. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
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shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sulaiman Nooristany whose telephone number is (571) 
270-1929. The examiner can normally be reached on M-F from 9 to 5. If attempts to 
reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, 
can be reached on (571) 272-6798. The fax phone number for the organization where 
this application or proceeding is assigned is 571-273-8300. Information regarding the 
status of an application may be obtained from the Patent Application Information 
Retrieval (PAIR) system. Status information for published applications may be obtained 
from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the 
PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to 
the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217- 
9197 (toll-free). 

Sulaiman Nooristany 01/18/2008 

JEFFREY PWU 
SUPERVISORY PATENT EXAMINER 




